home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0354.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  3.9 KB  |  76 lines
  1. Steve Putz wrote:
  2. >I like the idea of your suggested INPUT tag.  It seems like a logical
  3. >extension of the current protocol, and I can think of many uses for it,
  4. >including form-based queries and maybe even a server-based Hypertext editor
  5.                                                =============================
  6. >running on a very simple generic client.
  7. >
  8. >Steve Putz
  9. >Xerox PARC
  10. >
  11. >
  12. This raises the question of smart servers vs smart clients.
  13.  
  14. How much does the client need to know about format conversion ? The client
  15. knows what formats it understands (maybe extensible through a system like
  16. a MIME mailcap), but does it need to know about how to convert between
  17. different formats ? Adding format conversion into the clients will make
  18. them much more complicated, which is usually not a good thing (witness
  19. the success of POP over IMAP in the PC mail market: POP is simple minded,
  20. easy to implement and as a result widespread; IMAP is a rather nice protocol,
  21. fairly powerful, but more difficult to implement (though not THAT difficult).
  22. RESULT: though IMAP is technically far superior to POP, POP is winning
  23. the war.)
  24.  
  25. Thus I think it would be a good idea to keep the clients simple, shunt
  26. the complexity where possible into the server (it doesnt matter much if
  27. ther are only one or two server implementations; it matters a great deal
  28. however if the clients are only limited to certain Unix boxes).
  29.  
  30. I think we can learn from the way the DNS works. The are two types of DNS
  31. queries: iterative and recursive. With an iterative query, the client
  32. (resolver) sends a query to one server. From the result it may be referred
  33. to another server, which it then queries and so on until it reaches a 
  34. conclusion. With a recursive query, the resolver (a stub resolver) sends
  35. the initial query (with the RR bit set) to a local server, which then does
  36. all the work. The protocol remains the same in both cases, the actual
  37. procedure of lookup remains the same, they differ only in whether the local
  38. resolver does all the work or simply punts it to a local server.
  39.  
  40. The best way to support small machines such as PCs, Macs, Amigas etc
  41. within the WWW would seem to me to support the concept of a stub client
  42. that merely throws everything at the server and leaves it to sort out the
  43. mess. When the stub client connects to the server it informs the server
  44. what formats it understands (lists out its wwwcap ?). Compatibility with
  45. existing clients can be maintained in that if a client doesn't inform the
  46. server of the formats it knows, we can asssume a minimum (HTML + plain
  47. text ?).
  48.  
  49. This can be extended further... consider a site running a firewall,
  50. limiting access to the outside to a few selected hosts (poor misguided
  51. people !). If I'm sitting on a PC and I'm reading a document with a link
  52. to another document outside my site, that link is useless to me because
  53. I cant access the outside world. On the other hand a central site server
  54. might have external access, thus if I can punt the query to the server
  55. and say "you go fetch this for me" everything is hunkydory. The underlying
  56. protocol doesn't change, all that happens is that I can ask any server
  57. to get me the answer, rather than just the right one.
  58.  
  59. Again look at the DNS. The great advantage of stub resolver is that they
  60. lead to a centralised cache at the local server. If we punt www queries
  61. to a local server we get the same: the ability to build a cache of the
  62. information regularly used by the locals (I'm writing from a research lab
  63. with a heavy slant towards high energy physics - thus there is likely
  64. to a slant in the documents that users around here want; cacheing this
  65. working set would be a big win.)
  66. (For this cacheing to work well we'd need to associate a time to live
  67. with each document - again like the DNS).
  68. It should be possible to cache format conversions as well.
  69.  
  70. Anyway, these are just some ideas, maybe useful maybe not.
  71.  
  72. Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk
  73.  
  74.  
  75.  
  76.